As the consumer electronics industry continues to mature, and the capabilities of processors increase, more devices have become available for public use that allow for the transfer of data between devices and more applications have become available that operate based on this transferred data. Of particular note are the Internet and local area networks (LANs). These two innovations allow multiple users and multiple devices to communicate and exchange data between different devices and device types. With the advent of these devices and capabilities, users increasingly desire to receive a variety of services over these networks. Some common examples of these services (or applications) are video on demand (VoD), Internet Protocol television (IPTV) and audio files. Additionally, many of these services can be received at different service quality levels, e.g., in different formats and based upon a variety of parameters. Some of these parameters include, for example, the user's output device capabilities, available bandwidth, service agreements and network resource availability.
Methods currently exist to allow a user to ask for and receive a service over a network. A basic system describing exemplary elements which can be involved in such communications will now be described with respect to FIG. 1. These elements include an end user 102, a resource manager (RM) 104, a service manager (SM) 106, an application function (AF) 108, and a network 110. These components are typically able to communicate with each other over network 110, however most of the control functions regarding network resources are performed by the RM 104 while most of the control functions regarding service policies and sessions are performed by the SM 106. End user 102 interacts with a device (not shown), such as a computer with display, a television, an audio device or the like, used for disseminating the application sent by AF 108. Additionally, while network 110 is illustrated in FIG. 1 as being a single network in many working examples there are a number of different networks that are interconnected with one another.
Additionally, it is common for application and network services offered over a public access network to be provided and supported by a number of different operational entities or organizations. These organizations will play one or many business roles, and will also be part of one or several corporate entities. For example, there can be competing program distributors or a single company offering phone services, standard television programs and VoD movies. Thus it is easy to see how an end user could desire to interact with a variety of applications provided by different service providers through a multitude of networks, where the network resources could be shared at various times. One tool used to assist in defining what an end user can access over these networks from various service providers is a Service Level Agreement (SLA).
The relationship between the end user and the service provider is typically regulated through a specific agreement. The SLA is a contract between the end user and the service provider that defines a set of characteristics of the service delivery. This includes general technical aspects, such as bandwidth and availability of the services the user is authorized to access, and non-technical aspects, such as pricing, penalties or verifying methods. This relationship is generally established prior to an end user requesting a service from the AF.
After the details of a SLA are put into a format that the SM can understand, e.g., a program or database, an end user can request services. A currently existing message sequence for a service request, and resource negotiation associated therewith, will now be described with respect to FIG. 2. Initially, end user 202 sends a message 210 indicating the desire for a service to an AF 208. AF 208 then transmits a message 211 to SM 206 which allows the SM to initially verify that the end user 202 should be allowed access to that application. If the end user 202 is allowed access to the desired application, SM 206 then sends a message 212, based on the request and details of any SLA(s) involved, to RM 204. Message 212 contains a quality of service (QoS) request and other pertinent details regarding the request.
In this example, RM 204 is unable to provide the desired QoS, e.g., due to insufficient network resources being currently available, and sends a message 214 to SM 206 denying the request. SM 206 then sends another message 216 to RM 204 containing a lower QoS request for the same application. RM 204 again rejects the request and notifies SM 206 in message 218. This iterative process continues until SM 206 sends a message 220 with a request that RM 204 can grant. This acceptance message 222 is then sent from RM 204 to SM 206. At this point, SM 206 sends a message 224 to AF 208 which allows AF 208 to send the application 226 to end user 202. Application (service) 226 is sent to end user 202 based upon the allowable criteria and resources as designated by RM 204. It will be appreciated by those skilled in the art that this iterative method for resource negotiation may consume unnecessary bandwidth and introduce significant delay in the delivery of the service through the communication network.
Accordingly the exemplary embodiments described herein address the need for improving the messaging between a SM and a RM and the delivery of applications to an end user.